Headful PATCH /display previously restarted chromium to re-apply
--start-maximized against the new X root. The restart costs ~9s and
also wipes browser-side state (Emulation.* overrides, devtools
sessions). It turns out the restart isn't load-bearing: mutter reflows
a window in windowState=maximized (or fullscreen) onto the new root
whenever the X root resizes via xrandr/Neko. The server just has to
make sure the window is in that state.

This replaces the restart on the Xorg branch of PatchDisplay with a
single Browser.setWindowBounds{windowState:"maximized"} call. The
helper is idempotent: it early-returns when the window is already
maximized or fullscreen, so kiosk windows stay in fullscreen. Callers
that still want the legacy restart can pass restart_chromium=true.

The explicit-bounds form of setWindowBounds (windowState:"normal" with
{left,top,width,height}) is intentionally NOT used: once a window is
in normal state mutter stops auto-tracking RANDR events, which would
silently break subsequent resizes.

New e2e test e2e_display_resize_window_test.go covers headless fast
path, --start-maximized + neko, kiosk + fullscreen, and a
force-maximized-via-CDP scenario. Each subtest asserts:
- X root reaches the requested size (xrandr Screen 0: current WxH)
- renderer screen.* and outer{Width,Height} converge
- CDP windowState is preserved across the resize
- CDP windowId is stable (proves no chromium restart)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

After the legacy restart_chromium path was removed, two of the five
TestDisplayResizeChromiumWindow scenarios became strictly redundant:

  - headful_kiosk_no_restart: passes restart_chromium=false explicitly,
    but the field is a no-op on the Xorg branch — functionally
    identical to headful_kiosk.
  - headful_force_maximized_no_restart: forces windowState=maximized
    via CDP at baseline, then resizes. Was useful while investigating
    whether mutter's "maximized window reflows on RANDR" invariant
    holds; headful_start_maximized now covers the same hot path with
    production-equivalent CHROMIUM_FLAGS.

Both also flaked in CI when running later in a heavy e2e suite —
neko/mutter occasionally fails to apply its 1920x1080 desktop.screen
startup mode under load, leaving the X root at the dummy DDX's
3840x2160 default and breaking the resize assertions. Running them
locally or earlier in the suite passes consistently, so it's an
environmental flake, not a code regression.

Also remove the now-unused helpers setChromiumWindowStateCDP,
waitForWindowState, baselineOrForcedState, and the
forceMaximizeAtBaseline / restartChromium fields on resizeScenario.

The remaining three subtests cover every production path: headless
CDP fast path, headful --start-maximized + neko, headful kiosk +
fullscreen.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Three follow-ups addressing review feedback:

1. xrandr targets DUMMY0 (or KERNEL_IMAGES_XRANDR_OUTPUT env override),
   not "default". The headful Xorg dummy driver does not expose a
   "default" output, so `xrandr --output default --mode ...` exits 0
   without applying anything. This affects only the non-Neko Xorg path
   (production runs with Neko enabled, which doesn't touch xrandr), but
   left the path silently broken.

2. CDP maximize re-assert failure is now fatal. Previously logged a
   warning and returned 200; if the window happened to be in normal
   state and the CDP call failed, the server returned success with the
   browser window stuck at the old size. Now the resize fails closed
   with a 500 so the caller sees the mismatch.

3. TestDisplayResizeChromiumWindow now asserts windowID stability and
   windowState preservation across both resizes. Previously logged but
   never asserted; a silent chromium restart regression would have
   slipped through.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

The else branch for refreshRate <= 0 built `xrandr --output DUMMY0
--size WxH`. `--size` is xrandr's legacy global screen option (long
form of `-s`) and cannot be combined with `--output`; per-output
resizing requires `--mode <name>`. The mismatched flag combination
either silently no-ops or errors depending on the xrandr version.

The branch was effectively dead — the schema enum
(PatchDisplayRequestRefreshRate) only permits 10/25/30/60 and
getCurrentResolution synthesizes 60 when xrandr is silent — but the
footgun should not stay in the tree. Normalize refreshRate to 60 when
non-positive and always go through the named modeline.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

cdpclient had three near-identical copies of "Target.getTargets →
unmarshal → loop for type=page → extract targetId" — SetWindowBoundsMaximized,
GetWindowBounds, and SetDeviceMetricsOverride each carried ~20 lines of
the same routine. Pulls them into a private firstPageTargetID(ctx)
helper. DispatchStartURL has a different shape (walks all page targets,
closes extras, falls back to creating one) so it stays as-is.

Net 65 lines removed, no behaviour change.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>